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Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 
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This document may contain material from IETF Documents or IETF 
Contributions published or made publicly available before November 
10, 2008. The person(s) controlling the copyright in some of this 
material may not have granted the IETF Trust the right to allow 
modifications of such material outside the IETF Standards Process. 
Without obtaining an adequate license from the person(s) controlling 
the copyright in such materials, this document may not be modified 
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IESG Note 


EAP-FAST has been implemented by many vendors and it is used in the 
Internet. Publication of this specification is intended to promote 
interoperability by documenting current use of existing EAP methods 
within EAP-FAST. 


The EAP method EAP-FAST-GTC reuses the EAP type code assigned to EAP- 


GTC (6). The reuse of previously assigned EAP Type Codes is 
incompatible with EAP method negotiation as defined in RFC 3748. 
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Since EAP-GTC does not support method-specific version negotiation, 
the use of EAP-FAST-GTC is implied when used inside the EAP-FAST 
tunnel during authentication. This behavior may cause problems in 
implementations where the use of another vendor’s EAP-GTC is 
required. Since such support requires special case execution of a 
method within a tunnel, it also complicates implementations that use 
the same method code both within and outside of the tunnel method. 
If EAP-FAST were to be designed today, these difficulties could be 
avoided by utilization of unique EAP Type codes. Given these issues, 
assigned method types must not be re-used with different meaning 
inside tunneled methods in the future. 


Abstract 


The Flexible Authentication via Secure Tunneling Extensible 
Authentication Protocol (EAP-FAST) method enables secure 
communication between a peer and a server by using Transport Layer 
Security (TLS) to establish a mutually authenticated tunnel. Within 
this tunnel, a basic password exchange, based on the Generic Token 
Card method (EAP-GTC), may be executed to authenticate the peer. 
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1. Introduction 


EAP-FAST [RFC4851] is an EAP method that can be used to mutually 
authenticate a peer and server. This document describes the EAP-FAST 
inner EAP method, EAP-FAST-GTC, which is used to authenticate the 
peer through a basic password exchange. EAP-FAST-GTC was developed 
to support using cleartext passwords to authenticate to legacy user 
databases, to facilitate password change, and to support one time 
password features such as new pin mode. Message exchanges, including 
user credentials, are cleartext strings transferred within the 
encrypted TLS tunnel and thus are considered secure. For historical 
reasons, EAP-FAST-GTC uses EAP Type 6, originally allocated to EAP- 
GTC [RFC3748]. Note that EAP-FAST-GTC payloads used in EAP-FAST 
require specific formatting and therefore will not necessarily be 
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compatible with EAP-GTC mechanisms used outside of EAP-FAST. To 
avoid interference between these two methods, EAP-FAST-GTC MUST NOT 
be used outside an EAP-FAST tunnel, and EAP-GTC MUST NOT be used 
inside an EAP-FAST tunnel. All EAP-FAST-GTC packets sent within the 
TLS tunnel must be encapsulated in EAP Payload TLVs, described in 
[RFC4851]. 


It is assumed that a reader of this document is familiar with EAP- 
FAST [RFC4851]. 


1.1. Specification Requirements 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 


"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


2. EAP-FAST GTC Authentication 


All EAP-FAST-GTC packets inside EAP-FAST other than the empty 
acknowledgment packet MUST follow the "LABEL=Value" format. All 
Labels are in ASCII text and SHALL NOT contain the space character. 
Currently, three Labels are defined: 


o "CHALLENGE", the server request packet MUST be in the form of 
"CHALLENGE=Value", where Value is the server challenge, such as 
"please enter your password". 


o "RESPONSE", the peer response packet MUST be in the form of 
"RESPONSE=Value", where Value is the peer response. 


o "E", the server failure packet MUST be in the form of "E=Value", 
where Value is the error message generated by the server. 


If the peer or the server receives an EAP-FAST-GTC request or 
response that is not in the format specified above, it SHOULD fail 
the authentication by sending a Result TLV with a failure. 


After the TLS encryption tunnel is established and EAP-FAST 
Authentication phase 2 starts, the EAP server sends an EAP-FAST-GTC 
Request, which contains a server challenge. The server challenge is 
a displayable message for use by the peer to prompt the user. 


A peer MAY prompt the user for the user credentials, or decide to use 
the user credentials gained through some other means without 
prompting the user. The peer sends the user credentials back in the 
EAP-FAST-GTC Response using the following format: 


"RESPONSE=user@example.com\0secret" 
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where "user@example.com" is the actual username and "secret" is the 
actual password. The NULL character "\0" is used to separate the 
username and password. 


The username and password are included in a single message in the 
first response packet as an optimization by eliminating the inner 
method EAP-Identity exchange to save an extra round trip. 


Once the EAP-FAST server receives the user credentials, it SHOULD 
first validate the user identity with the Initiator ID (I-ID) 
[RFC5422] in the PAC-Opaque (Protected Access Credential) and if it 
matches, it will continue to authenticate the user with internal or 
external user databases. 


Additional exchanges MAY occur between the EAP-FAST server and peer 
to facilitate various user authentications. The EAP-FAST server 
might send additional challenges to prompt the peer for additional 
information, such as a request for the next token or a new pin in the 
one time password case, or a server failure packet to indicate an 
error. The peer displays the prompt to the user again and sends back 
the needed information in an EAP-FAST-GTC Response. The exchange 
ends when a Result TLV is received. 


An EAP-FAST-GTC server implementation within EAP-FAST uses the 
following format to indicate an error if an authentication fails: 


"R=eeeeeeeeece R=r M=<msg>" 
where: 
The "eeeeeeeeee" is the ASCII representation of a decimal error code 
corresponding to one of those listed below, though peer 
implementations SHOULD deal with codes not on this list gracefully. 
The error code need not be 10 digits long. 


Below is a complete list of predefined error codes: 


o 646 ERROR_RESTRICTED_LOGON_HOURS 


Indicates that access is attempted outside the allowed hours. 
Peer implementations SHOULD display the error message to the user 
and ask the user to try at a later time. 
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o 647 ERROR_ACCT_DISABLED 


Indicates that the requested account is disabled. Peer 
implementations SHOULD display the error message to the user, 
which helps the user to resolve the issue with the administrator. 


o 648 ERROR_PASSWD_EXPIRED 


Indicates that the password has expired and a password change is 
required. Peer implementations SHOULD prompt the user for a new 
password and send back the new password in the peer response 
packet. 


o 649 ERROR_NO_DIALIN_PERMISSION 


Indicates that access has been denied due to lack of dial-in 
permission. Peer implementations SHOULD display the error message 
to the user, which helps the user to resolve the issue with the 
administrator. 


o 691 ERROR_AUTHENTICATION_FAILURE 


Indicates that there was authentication failure due to an 
incorrect username or password. Based on the retry flag described 
below, peer implementations MAY prompt the user again for a new 
set of username and password or simply send back an empty 
acknowledgment packet to acknowledge the failure and go into the 
termination phase of the authentication session. 


o 709 ERROR_CHANGING_PASSWORD 
Indicates that the password change failed, most likely because the 
new password fails to meet the password complexity policy. Peer 
implementations SHOULD display the error message and prompt the 


user again for the new password. 


o 755 ERROR_PAC_I-ID_NO_MATCH 


Indicates that the PAC used to establish the EAP-FAST session 
cannot be used to authenticate to this user account. Based on the 
retry flag described below, peer implementations MAY prompt the 
user again for a new set of username and password or simply send 
back an empty acknowledgment packet to acknowledge the failure and 
go into the termination phase of the authentication session. 


The "r" is a single character ASCII flag set to ’1’ if a retry is 


allowed, and ’0’ if not. When the server sets this flag to ’1’, it 
disables short timeouts, expecting the peer to prompt the user for 
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new credentials and to resubmit the response. When the server sets 
this flag to ’0’, the peer SHOULD NOT prompt the user for new 
credentials to try again without restarting the EAP-FAST 
authentication from the beginning. 


The <msg> is human-readable ASCII text. Current implementations only 
support ASCII text. 


The server failure packet can be broken into Label/Value pairs using 
the space character as the separator. The only value that may 
contain the space character is the <msg> value, which is always the 
last value pair in the failure packet. The peer SHOULD ignore any 
unknown label/value pair in the failure packet. 


The error format described above is similar to what is defined in the 
Microsoft Challenge Handshake Authentication Protocol version 2 
(MSCHAPv2) [RFC2759], except for the omission of a server challenge. 
So if the EAP-FAST server is distributing MSCHAPv2 exchanges to the 
backend inner method server, it can simply return what the backend 
inner method server returns less the server challenge. In the case 
of connecting to a one time password or Lightweight Directory Access 
Protocol (LDAP) [RFC4511] server, the EAP-FAST server can translate 
the error message into this format. With the addition of the retry 
count, the peer can potentially prompt the user for new credentials 
to try again without restarting the EAP-FAST authentication from the 
beginning. The peer will respond to the error code with another EAP- 
FAST-GTC Response packet with both the new username and password, or 
in case of other unrecoverable failures, an empty EAP-FAST-GTC packet 
for acknowledgement. The peer uses empty EAP-FAST-GTC payload as an 
acknowledgment of the unrecoverable failure. 


If the EAP-FAST server finishes authentication for the EAP-FAST-GTC 
inner method, it will proceed to Protected Termination as described 
in [RFC4851]. In the case of an unrecoverable EAP-FAST-GTC 
authentication failure, the EAP server can send an EAP-FAST-GTC error 
code as described above, along with the Result TLV for protected 
termination. This way, no extra round trips will occur. The peer 
can acknowledge the EAP-FAST-GTC failure as well as the Result TLV 
within the same EAP-FAST packet. Once the server receives the 
acknowledgement, the TLS tunnel will be torn down and a clear text 
EAP-Failure will be sent. 


The username and password, as well as server challenges, MAY support 
non-ASCII characters. In this case, international username, 
password, and messages are based on the use of Unicode characters, 
encoded as UTF-8 [RFC3629] and processed with a certain algorithm to 
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ensure a canonical representation. The username and password input 
SHOULD be processed according to Section 2.4 of [RFC4282], and the 
server challenges SHOULD be processed according to [RFC5198]. 


Since EAP-FAST-GTC does not generate session keys, the MSKi (Master 
Session Key) used for crypto-binding for EAP-FAST will be filled with 
all zeros. 


3. Security Considerations 


The EAP-FAST-GTIC method sends password information in the clear and 
MUST NOT be used outside of a protected tunnel providing strong 
protection, such as the one provided by EAP-FAST. Weak encryption, 
such as 40-bit encryption or NULL cipher, MUST NOT be used. In 
addition, the peer MUST authenticate the server before disclosing its 
credentials. Since EAP-FAST Server-Unauthenticated Provisioning Mode 
does not authenticate the server, EAP-FAST-GTC MUST NOT be used as 
the inner method in this mode. EAP-FAST-GTC MAY be used in EAP-FAST 
authentication and Server-Authenticated Provisioning Mode [RFC5422], 
where the server is authenticated. Since EAP-FAST-GTIC requires the 
server to have access to the actual authentication secret, it is 
RECOMMENDED to vary the stored authentication validation data by 
domain so that a compromise of a server at one location does not 
compromise others. 


3.1. Security Claims 


This section provides the needed security claim requirement for EAP 
[RFC3748]. 


Auth. mechanism: Password based. 
Ciphersuite negotiation: No. However, such negotiation is provided 
by EAP-FAST for the outer authentication. 


Mutual authentication: No. However, EAP-FAST provides server-side 
authentication. 

Integrity protection: No. However, any method executed within the 
EAP-FAST tunnel is protected. 

Replay protection: See above. 

Confidentiality: See above. 

Key derivation: Keys are not generated, see Section 2. 
However, when used inside EAP-FAST, the 
outer method will provide keys. See 
[RFC4851] for the properties of those keys. 

Key strength: See above. 


Dictionary attack prot.: No. However, when used inside the EAP-FAST 
tunnel, the protection provided by the TLS 
tunnel prevents an off-line dictionary 
attack. 
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Fast reconnect: 


Cryptographic binding: 


Session independence: 
Fragmentation: 
Key Hierarchy: 


Channel binding: 


4. IANA Considerations 
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No. However, EAP-FAST provides a fast 
reconnect capability that allows the reuse 
of an earlier session authenticated by EAP- 
FAST-GTC. 

No. Given that no keys are generated, EAP- 
FAST-GTC or its use within EAP-FAST cannot 
provide a cryptographic assurance that no 
binding attack has occurred. EAP-FAST-GTC 
is required only to run within a protected 
tunnel, but even the use of the same 
credentials in some other, unprotected 
context might lead to a vulnerability. Asa 
result, credentials used in EAP-FAST-GTC 
SHOULD NOT be used in other unprotected 
authentication mechanisms. 

No. However, EAP-FAST provides session 
independence. 

No. However, EAP-FAST provides support for 
this. 

Not applicable. 

No, though EAP-FAST can be extended for 
this. 


EAP-FAST-GTC uses the assigned value of 6 (EAP-GTC) for the EAP Type 


in [RFC3748]. 


This document defines a registry for EAP-FAST-GTC error codes when 


running inside EAP-FAST, 


named "EAP-FAST GTC Error Codes". It may be 


assigned by Specification Required as defined in [RFC5226]. A 
summary of the error codes defined so far is given below: 


o 646 ERROR_RESTRICTED_LOGON_HOURS 


o 647 ERROR_ACCT_DISABLED 


o 648 ERROR_PASSWD_EXPIRED 


o 649 ERROR_NO_DIALIN_PERMISSION 


o 691 ERROR_AUTHENTICATION_FAILURE 


o 709 ERROR_CHANGING_PASSWORD 


o 755 ERROR_PAC_I-ID_NO_MATCH 
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6. 


6. 


No IANA registry will be created for Labels, as current 
implementations only support the Labels defined in this document and 
new Labels are not expected; if necessary, new Labels can be defined 
in documents updating this document. 
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